Flowcharts have long been used for documenting steps to troubleshoot problems. Call centers and support services for software companies often create flowcharts that detail diagnostic steps for common problems. Information Technology (IT) professionals use the flowcharts to ask users a series of questions designed to methodically lead the IT professional to a root cause of a problem and to eliminate other possible causes. For example, a flowchart for a problem related to web browsing may include steps for ensuring that the user's computer has Internet connectivity, that the computer is functioning normally, that the computer was able to resolve the name of a server to an Internet Protocol (IP) address using the Domain Name System (DNS), and so forth.
Web-based static flowcharts for troubleshooting exist today that guide readers through a defined process to determine the root cause of a problem and provide the steps to resolve the problem. Many IT departments provide internal websites (e.g., intranets) with flowcharts and knowledge bases related to previously seen problems. Past attempts to make flowcharts interactive have added pop-up dialogs that appear as a user clicks a step or hovers over a step to provide additional information about the step. Some solutions have also provided clickable boxes that perform a diagnostic or corrective step. For example, if the first step is creating a user account, then clicking the box may open a web page that describes how to create a user account.
One problem with static troubleshooting flowcharts and past attempts at interactivity is that they show the entire troubleshooting process at the same time. For complex troubleshooting scenarios, the result is visual clutter and the process to identify the root cause can be difficult to follow. Users can easily lose their place in the process when switching between a web browser and troubleshooting tools. This leads many readers to print the flowchart and then manually indicate their current place in the path through the flowchart on the printed copy.
Another problem with static flowcharts is that there is no feedback to flowchart authors, and by extension, their product teams, to indicate how the flowcharts are being used, if they are effective in solving customer problems, or if there are product improvements that can be made to address root causes or make troubleshooting more efficient through tools. For example, a static flowchart author cannot easily determine which paths through the flowchart are the most commonly followed so that future enhancements to products can mitigate or eliminate the most common types of problems. Flowchart authors may not know whether a given path through the flowchart to a root cause actually solves a reader's problem.
Additionally, with a static flowchart, it is much more difficult for a reader to glean and understand the relationships between system components and the use of tools in an overall troubleshooting methodology. In other words, a static troubleshooting flowchart helps a reader solve a problem, but does not teach them how to troubleshoot without the flowchart or to have a deeper understanding of troubleshooting tool use or system component interaction to troubleshoot problems that the flowchart does not address. To paraphrase a Chinese proverb, the static troubleshooting flowchart gives a reader a fish, but does not teach the reader how to fish.